In response to this:

Analysis / Root cause:

useShipwrightBreadcrumbsFor is a React hook containing 6 sub-hooks (useActivePerspective, useParams, useLocation, useTranslation, useConsoleSelector, useMemo) that was incorrectly passed as a plain callback via the breadcrumbsFor prop to DetailsPage.

Inside ConnectedPageHeading, breadcrumbsFor is called conditionally based on data loading state:

breadcrumbs={!_.isEmpty(data) ? breadcrumbsFor(data) : null}

This violates React's Rules of Hooks. On the first render (data empty), 0 hooks are invoked via breadcrumbsFor; on re-render (data loaded), 6 hooks are invoked.

This bug was latent since commit e98f1e58b1 (Aug 2024, ODC-7632). On OCP 4.19, ConnectedPageHeading had no hooks of its own, so React couldn't detect the violation. On OCP 4.20+, commit f803a25cb7 added 3 hooks to ConnectedPageHeading, causing React to detect the hook count mismatch (3 → 9) and throw error #310: "Rendered more hooks than during the previous render."

All 4 Shipwright detail pages are affected: Build, BuildRun, BuildStrategy, and ClusterBuildStrategy.

Linked Jira: https://issues.redhat.com/browse/OCPBUGS-84214
Support Cases: 04362500, 04425432, 04430794

Solution description:

Refactored all 4 affected detail pages to call useShipwrightBreadcrumbsFor unconditionally at the component level using their existing use*Model() hooks, and pass the result as a closure:

// Before (broken — hook passed as callback, called conditionally)
<DetailsPage breadcrumbsFor={useShipwrightBreadcrumbsFor} />

// After (fixed — hook called at top level, result passed as closure)
const model = useBuildModel();
const breadcrumbs = useShipwrightBreadcrumbsFor(model);
<DetailsPage breadcrumbsFor={() => breadcrumbs} />

This follows the established pattern used by the knative plugin (ServiceDetailsPage.tsx).

Also changed useShipwrightBreadcrumbsFor to accept a K8sModel directly instead of a K8sResourceKind, and removed the now-dead resourceToModel function (30 lines).

Test setup:

1. OCP 4.20+ cluster with the Builds for Red Hat OpenShift Operator installed (v1.7.1 or v1.7.2)
2. At least one ClusterBuildStrategy deployed (e.g., buildah — typically installed by the operator automatically)

Test cases:

1. Navigate to /k8s/cluster/shipwright.io~v1beta1~ClusterBuildStrategy/buildah — page should render without crash, breadcrumbs should show correctly
2. Navigate to a namespaced BuildStrategy, Build, and BuildRun detail page — all should render without crash
3. Verify breadcrumb links navigate back to the correct list pages
4. Verify tab switching (Details, YAML, BuildRuns, Events, Logs) works without errors
5. Verify no React warnings or errors in the browser console

Browser conformance:

• Chrome
• Firefox
• Safari (or Epiphany on Linux)

Additional info:

• 5 files changed, 21 insertions, 41 deletions — all changes confined to shipwright-plugin
• Zero console core changes
• All existing unit tests pass (49 tests across 9 suites)
• TypeScript compiles clean with zero errors
• Backport needed to release-4.20 and release-4.21

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

• bug is open, matching expected state (open)
• bug target version (5.0.0) matches configured target version for branch (5.0.0)
• bug is in the state ASSIGNED, which is one of the valid states (NEW, ASSIGNED, POST)

In response to this:

Analysis / Root cause:

useShipwrightBreadcrumbsFor is a React hook containing 6 sub-hooks (useActivePerspective, useParams, useLocation, useTranslation, useConsoleSelector, useMemo) that was incorrectly passed as a plain callback via the breadcrumbsFor prop to DetailsPage.

Inside ConnectedPageHeading, breadcrumbsFor is called conditionally based on data loading state:

breadcrumbs={!_.isEmpty(data) ? breadcrumbsFor(data) : null}

This violates React's Rules of Hooks. On the first render (data empty), 0 hooks are invoked via breadcrumbsFor; on re-render (data loaded), 6 hooks are invoked.

This bug was latent since commit e98f1e58b1 (Aug 2024, ODC-7632). On OCP 4.19, ConnectedPageHeading had no hooks of its own, so React couldn't detect the violation. On OCP 4.20+, commit f803a25cb7 added 3 hooks to ConnectedPageHeading, causing React to detect the hook count mismatch (3 → 9) and throw error #310: "Rendered more hooks than during the previous render."

All 4 Shipwright detail pages are affected: Build, BuildRun, BuildStrategy, and ClusterBuildStrategy.

Linked Jira: https://issues.redhat.com/browse/OCPBUGS-84214
Support Cases: 04362500, 04425432, 04430794

Solution description:

Refactored all 4 affected detail pages to call useShipwrightBreadcrumbsFor unconditionally at the component level using their existing use*Model() hooks, and pass the result as a closure:

// Before (broken — hook passed as callback, called conditionally)
<DetailsPage breadcrumbsFor={useShipwrightBreadcrumbsFor} />

// After (fixed — hook called at top level, result passed as closure)
const model = useBuildModel();
const breadcrumbs = useShipwrightBreadcrumbsFor(model);
<DetailsPage breadcrumbsFor={() => breadcrumbs} />

This follows the established pattern used by the knative plugin (ServiceDetailsPage.tsx).

Also changed useShipwrightBreadcrumbsFor to accept a K8sModel directly instead of a K8sResourceKind, and removed the now-dead resourceToModel function (30 lines).

Test setup:

1. OCP 4.20+ cluster with the Builds for Red Hat OpenShift Operator installed (v1.7.1 or v1.7.2)
2. At least one ClusterBuildStrategy deployed (e.g., buildah — typically installed by the operator automatically)

Test cases:

1. Navigate to /k8s/cluster/shipwright.io~v1beta1~ClusterBuildStrategy/buildah — page should render without crash, breadcrumbs should show correctly
2. Navigate to a namespaced BuildStrategy, Build, and BuildRun detail page — all should render without crash
3. Verify breadcrumb links navigate back to the correct list pages
4. Verify tab switching (Details, YAML, BuildRuns, Events, Logs) works without errors
5. Verify no React warnings or errors in the browser console

Browser conformance:

• Chrome
• Firefox
• Safari (or Epiphany on Linux)

Additional info:

• 5 files changed, 21 insertions, 41 deletions — all changes confined to shipwright-plugin
• Zero console core changes
• All existing unit tests pass (49 tests across 9 suites)
• TypeScript compiles clean with zero errors
• Backport needed to release-4.20 and release-4.21

Summary by CodeRabbit

• Refactor
• Refactored breadcrumb generation across multiple detail pages for improved consistency and code organization.
• Streamlined breadcrumb computation logic for better maintainability.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

Walkthrough

This PR refactors breadcrumb generation across the Shipwright plugin by shifting responsibility from the utility hook to the consuming page components. The useShipwrightBreadcrumbsFor hook is simplified to accept a K8sModel parameter directly (removing internal resource-to-model conversion logic), and four detail page components now explicitly call their respective model hooks, derive breadcrumbs, and pass precomputed breadcrumbs to DetailsPage via callbacks instead of passing the hook reference itself. The change consolidates model-dependent logic into pages where the model context originates.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

• bug is open, matching expected state (open)
• bug target version (5.0.0) matches configured target version for branch (5.0.0)
• bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)

In response to this:

/jira refresh

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

In response to this:

/cherry-pick release-4.22 release-4.21

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

In response to this:

/verified by claude

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

• frontend/OWNERS [logonoff]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

In response to this:

Analysis / Root cause:

useShipwrightBreadcrumbsFor is a React hook containing 6 sub-hooks (useActivePerspective, useParams, useLocation, useTranslation, useConsoleSelector, useMemo) that was incorrectly passed as a plain callback via the breadcrumbsFor prop to DetailsPage.

Inside ConnectedPageHeading, breadcrumbsFor is called conditionally based on data loading state:

breadcrumbs={!_.isEmpty(data) ? breadcrumbsFor(data) : null}

This violates React's Rules of Hooks. On the first render (data empty), 0 hooks are invoked via breadcrumbsFor; on re-render (data loaded), 6 hooks are invoked.

This bug was latent since commit e98f1e58b1 (Aug 2024, ODC-7632). On OCP 4.19, ConnectedPageHeading had no hooks of its own, so React couldn't detect the violation. On OCP 4.20+, commit f803a25cb7 added 3 hooks to ConnectedPageHeading, causing React to detect the hook count mismatch (3 → 9) and throw error #310: "Rendered more hooks than during the previous render."

All 4 Shipwright detail pages are affected: Build, BuildRun, BuildStrategy, and ClusterBuildStrategy.

Linked Jira: https://issues.redhat.com/browse/OCPBUGS-84214
Support Cases: 04362500, 04425432, 04430794

Solution description:

Refactored all 4 affected detail pages to call useShipwrightBreadcrumbsFor unconditionally at the component level using their existing use*Model() hooks, and pass the result as a closure:

// Before (broken — hook passed as callback, called conditionally)
<DetailsPage breadcrumbsFor={useShipwrightBreadcrumbsFor} />

// After (fixed — hook called at top level, result passed as closure)
const model = useBuildModel();
const breadcrumbs = useShipwrightBreadcrumbsFor(model);
<DetailsPage breadcrumbsFor={() => breadcrumbs} />

This follows the established pattern used by the knative plugin (ServiceDetailsPage.tsx).

Also changed useShipwrightBreadcrumbsFor to accept a K8sModel directly instead of a K8sResourceKind, and removed the now-dead resourceToModel function (30 lines).

Test setup:

1. OCP 4.20+ cluster with the Builds for Red Hat OpenShift Operator installed (v1.7.1 or v1.7.2)
2. At least one ClusterBuildStrategy deployed (e.g., buildah — typically installed by the operator automatically)

Test cases:

1. Navigate to /k8s/cluster/shipwright.io~v1beta1~ClusterBuildStrategy/buildah — page should render without crash, breadcrumbs should show correctly
2. Navigate to a namespaced BuildStrategy, Build, and BuildRun detail page — all should render without crash
3. Verify breadcrumb links navigate back to the correct list pages
4. Verify tab switching (Details, YAML, BuildRuns, Events, Logs) works without errors
5. Verify no React warnings or errors in the browser console

Browser conformance:

• Chrome
• Firefox
• Safari

Backport plan

4.22, 4.21, 4.20

Additional info:

• 5 files changed, 21 insertions, 41 deletions — all changes confined to shipwright-plugin
• Zero console core changes
• All existing unit tests pass (49 tests across 9 suites)
• TypeScript compiles clean with zero errors

Summary by CodeRabbit

• Refactor
• Refactored breadcrumb generation across multiple detail pages for improved consistency and code organization.
• Streamlined breadcrumb computation logic for better maintainability.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

In response to this:

/cherry-pick release-4.22 release-4.21

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.